Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/dsp/dspgroup/cis_dsp.arc/CIS_DSP6.TXT

Text File | 1988-09-08 | 13.0 KB | 337 lines

#: 80458 S17/TAPR NNC/DSP
    25-Aug-88  17:01:04
Sb: #80382-Rick's UID
Fm: Barry McLarnon VE3JF 71470,3651
To: Rick Hambly WB2TNL 72117,3530

Duly noted.  Thanks Rick.  Seldom send any messages, eh?  Time to set some bait
then!  How about some thoughts from you on what principles we should be
following in designing DSP modems for HF?  How would you do 300 bps and
(especially) what about 1200 or higher?

Barry

PS: How are things at ARINC these days?  Is HF ACARS still alive and kicking?

#: 80551 S17/TAPR NNC/DSP
    27-Aug-88  00:58:22
Sb: Hardware Progress
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

We are busily working out systems level issues on the hardware design.  Chuck
is finishng s detail on the PACSAT CPU, then will do layout in earnest for the
DSP 1.

We are designing around the Ten Tec B series all metal cabinet.  We plan on a
PC board on the rear panel to do all I/O and translate all levels to CMOS and
-5/+5 analog.  Connectors planned are (2) DA-15S for radio I/O (PTT, Tx Audio,
Rx Audio, RFDCD, GND, UP to +5v, UP to GND, DOWN to +5V, DOWN to GND, another
GND, two CMOS outputs from the DSP board, two CMOS outputs from the GPP board,
one spare -- the UP and DOWN are for microphone tuning ala the PSK modem); (2)
DC-37S (one for 16 bit high speed DSP input, one for 16 bit high speed DSP
output); (1) DB25S for Centronics printer output (same pinout as IBM PC printer
port); (1) DE9S for RS232 serial I/O (same connector as IBM PC/AT); (1) DIN
8-pin for modem disconnect that corresponds to PSK modem; (4) RCA phono
connectors - 2 for speaker inputs (radio 1 and radio 2) one for CW output + to
GND, one for CW output - grid block keying; (1) power connector like TNC 2.

If you think we need any other I/O on this thing for the first pass, let us kno
ASAP!  The I/O board getslayed out first!

We are also planning a front panel PC board.  Will have several LEDs, some
predefined some undefined, a 16-position thumbwhhel switch for application
selection; reset, power and maybe a couple undefined switches.

Comments?

#: 80591 S17/TAPR NNC/DSP
    27-Aug-88  23:11:15
Sb: PIII.ASM
Fm: John Conner WD0FHG 72165,743
To: Bob McGwier N4HY 74615,1366

Bob;

Had a call this afternoon (also yesterday but not at home) from Junior
DeCastro, PY2BJO.  He received his disk ok and seemed quite pleased with them.
A couple of other hams were in the background playing with Phil's most
important contribution to ham radio |->.

His big question was how do you use PIII.ASM. I told him I'd send you a message
asking for more info.  I gather he is on AMSAT Telemail, send any thing you
have there (and copy it here).

I am having Andy send him the current PSR if he is not on the TAPR list (we'll
check the mailing list for others).

Guess you are on the way home from what Andy said.  I'll be in Montreal for the
next two weeks. Will try to check in here.  Won't be as easy late next spring,
looks like I'll be spending two to three MONTHS in Beijing and at least two
weeks in India. (If I can get all of the 10 year old digital filters to run on
the new machines.)

Do you know Parks or Burris by any chance???

John

#: 80704 S17/TAPR NNC/DSP
    30-Aug-88  02:00:09
Sb: microsat reset PROM
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson 76246,565

I finished a C program to generate the microsat reset PROM contents tonite, &
shipped it (electronically) to WB6HHV.  He will check it for sanity, then burn
a PROM & test it.

One thing we noted tonite, while looking over the latest schematics.. We're
concerned about the level-sensitive use of the reset output of the reset PROM.
It is intended that the PROM get its clock & data input directly from the
manchester decoder chip.  This means that depending on the design of the modem,
or whether the modem is working there may not be a clock to the PROM.  So, in a
case like this, the PROM might just sit in the state where the reset output is
low (true). One simple solution would be to capacitively couple the reset
output of the PROM to the reset input of 555 watchdog.  This adds only 1
capacitor, and i think it fixes all cases.

#: 80748 S17/TAPR NNC/DSP
    30-Aug-88  21:28:13
Sb: #80591-PIII.ASM
Fm: Bob McGwier N4HY 74615,1366
To: John Conner WD0FHG 72165,743

No I don't know either one of them.  Wish I did.  The PARK-BURRUS algorithms
for the TMS320C10 are what I am adapting to the Model 10.  They need two
things: TBLW and TBLR to program memory rather than the I/O read to memory and
we need one half more butterfly to do a half size complex FFT (N/2) to do a
size N FFT on real data.  That is taking work to get it efficient.  I have let
it slide while a lot of PACSAT software goes on.

On PIII.ASM, it needs a PC based program that recognizes sync vectors, idles,
and then decodes data blocks.  Phil has just such a beast but it has too much
dangerous information in it.  I will attempt to get that stuff going without
the dangerous stuff in it and then it will be easy to use it with the AO-13
beacon.

I want to reiterate that all of this stuff is going to slide until the PACSAT
obligations are fulfilled.

Bob




#: 80751 S17/TAPR NNC/DSP
    30-Aug-88  21:28:50
Sb: back on
Fm: Bob McGwier N4HY 74615,1366
To: All

I am back on from NJ Bob




#: 80752 S17/TAPR NNC/DSP
    30-Aug-88  21:42:05
Sb: #80704-#microsat reset PROM
Fm: Lyle Johnson, WA7GXD 76246,565
To: Franklin Antonio, N6NKF 76337,1365 (X)

Franklin,

Yes, I agree that we should couple this capacitively.  Will we need any gating
to add two or three reset proms rather than only one?  I think there was some
concern expressed in Boulder that one is great but two or three are wonderful
in case a receiver channel goes out and the spacecraft goes berserk...

Anyway, sounds like good progress.  We need to get the schematic to Jim, WA4ONG
so he can include it on the PC board layout.

Cheers,

Lyle

*** There is a reply:   80760

*** More ***

#: 80760 S17/TAPR NNC/DSP
    30-Aug-88  23:43:33
Sb: #80752-microsat reset PROM
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565

We agree that it's a good idea to have reset proms on 2 channels.  Haven't
given thought to problem of oring the reset signals tgether.  My offhand guess
is that we need a gate.  I keep thinking there ought to be a way to do it with
a 2nd capacitor instead of a gate, but i don't see how to make that work yet.


#: 80756 S17/TAPR NNC/DSP
    30-Aug-88  22:28:51
Sb: #Rick's UID
Fm: Rick Hambly WB2TNL 72117,3530
To: Barry McLarnon VE3JF 71470,3651 (X)

Just a quick reply to let you know I'mm relly here.  No HF ACARS is not alive
and well, but I hope it's only dormant.  There is E-ACARS (enhanced VHF) and
I-ACARS (International i.e.: Satcom).  Long story.

I designed an HF modem for Harris Corp. a few years ago.  The "right way" is
either "serial" or "Parallel".  Serial modem is single tone with 8-phase + AM
modulation (or variant) with real-time adaptive equalization.  Not practical
for anyone much less hams ($50K per modem).  "Parallel" uses many tones in 3KHz
bandwidth.  Optimum baud rate is 40 to 100.  The modem I did was 44.44 baud,
QPSK, 39 tones, which gives 44.44 * 2 * 39 = 3466 bps. With appropriate FEC
this gave 2400 bps effective user throughput with near perfec copy in the worst
of conditions.  However, the training sequence (preamble) was long and the FEC
and interleaving (at lower rates) caused delays which were not compatible with
our concept of "packet radio".  The problems are much like satellite link
delays only worse.

Tom had an interesting and potentially inexpensive way to get some of the
benefits without all the cost.  The efficiency (data rate/BW) was not as good,
but it might be far better than what we have available and at a cost which the
DSP project can handle.  I don't want to steal his thunder so I'll leave that
idea for him to describe for now.

For a variety of reasons I am particularly interested in any work (HF or VHF)
using MSK modulation.

Rick.



*** There is a reply:   80761

*** More ***

#: 80761 S17/TAPR NNC/DSP
    30-Aug-88  23:51:07
Sb: #80756-Rick's UID
Fm: Franklin Antonio, N6NKF 76337,1365
To: Rick Hambly WB2TNL 72117,3530

Hello Rick.  My concern with "parallel" modems for amateur radio use has always
been the high peak-to-average power ratio of the multitone signal. The typical
ham HF rig is peak power limited.  If we generate a signal with 20:1
peak-to-average power ratio, then the average power out of the xmitter has to
be backed off at least 13db.  Any comments on this issue?

#: 80806 S17/TAPR NNC/DSP
    01-Sep-88  01:38:38
Sb: #80748-PIII.ASM
Fm: Paul Williamson, KB5MU/6 75265,367
To: Bob McGwier N4HY 74615,1366

Do we need somebody who knows Parks and Burrus?  I was a student of Parks and
had some extracurricular contact with Burrus, both at Rice.  They might even
remember me!

#: 80839 S17/TAPR NNC/DSP
    01-Sep-88  22:58:44
Sb: #80806-PIII.ASM
Fm: Bob McGwier N4HY 74615,1366
To: Paul Williamson, KB5MU/6 75265,367 (X)

Don't know why John Connor asked.  I am sure he will light up if you can be of
help there.

Bob

#: 80974 S17/TAPR NNC/DSP
    04-Sep-88  14:13:27
Sb: #Parallel Modems
Fm: Rick Hambly WB2TNL 72117,3530
To: Franklin Antonio, N6NKF 76337,1365 (X)

I agree that the peak-to-average ratio of a parallel, muti-tone modem appears
at first to be a serious problem.  It takes a great deal of analysis, but for
the 39-tone military modem I worked on we found that base band clipping of 10 -
15 db (if memory serves) generated so little distortion as to be of no concern.
This left us with acceptable waveform. You don't think the problem was any less
for a 10KW HF military transmitter?  It becomes one of cubic $$$'s.

Tom's idea is a one-of-many (e.g.: 1 of 16) scheme which avoids the
peak-to-average problem, but lacks some of the modulation to data rate
compression - 1 of 16 has a 4:1 rate comression which gives only 300 bps for 75
baud.  At least the 300bps would propagate on 80 meters which is more than it
does now.  A 16 tone QPSK waveform gives 32:1 rate compression which could
support 2400bps with 100 baud and have room for FEC.  But the peak-to-average
power problem is back.  Note the FEC - in part it helps overcome the errors due
to amplitude clipping.  There is an optimum balance between clipping which ups
the average power and the use of FEC which provides coding gain.



*** There are replies:  81034, 81050

*** More ***

#: 81034 S17/TAPR NNC/DSP
    05-Sep-88  11:25:59
Sb: #80974-Parallel Modems
Fm: Bob McGwier N4HY 74615,1366
To: Rick Hambly WB2TNL 72117,3530

Hiya Rick:

Glad to see you on here.  What's new?  The HF modem work ought to move along
after we get this PACSAT stuff behind us.  It is gobbling valuable DSP time. If
we could be guaranteed good SNR's, I could do the QPSK modem using several dB
implementation loss versions of the modems.  Clock recovery by zero crossings
and not another PLL, and IIR filters with less than great group delay
performance rather than FIR filters, etc.  It just won't play if it doesn't
OCCASIONALLY copy a weak signal anyway.  Hams are super picky folks.  I am
already worrying about ONE of these signals occupying as much spectrum as 800
Hz shift RTTY

Bob



*** More ***

#: 81050 S17/TAPR NNC/DSP
    05-Sep-88  16:04:41
Sb: #80974-Parallel Modems
Fm: Franklin Antonio, N6NKF 76337,1365
To: Rick Hambly WB2TNL 72117,3530

I can see how the clipping can work with FEC, but i'm not sure i see how the
clipping can work without FEC.  Assuming you have lots of tones, the high peaks
are low probability events, so the badness induced by clipping doesn't happen
very often.  ... but it still happens!

Also, you mentioned "baseband" clipping.  Unfortunately, unless the local
oscillator is phase locked to whatever generated your baseband waveforms,
baseband clipping does not imply that the RF waveform (frequency shifted
version of the baseband waveform) is amplitude limited.

#: 81161 S17/TAPR NNC/DSP
    07-Sep-88  01:08:58
Sb: #80974-Parallel Modems
Fm: Tom Clark W3IWI 71260,3640
To: Rick Hambly WB2TNL 72117,3530

Hi Gang -- I've been over my head with PACSAT, work and getting ready for
the networking conference (I'm sorta the local host, I guess, by default) so
DSP has taken a back seat here too. At a work meeting last week when
somebody tried to assign me a new task, my response was that it's going to
be Thanksgiving before I have time to take a sh*t!

Anyway on the HF modem thread -- another compromise idea that we bandied
around a few months ago, which perhaps should be reconsidered: The 2- or 3-
of N schemes compress more bits/baud and won't have as much problem with
peak/avg power ratios. Good ole DTMF works pretty well with two one-of-four
tones after all, and 4 bits/baud ain't that bad. Two one-of-6's would get
5 bits/baud, and two one-of-8's would get 6 bits/baud.

Clearly for the HF world we want to shoot for a decent bit rate at a rate
of 50 baud or less to get thru nasty old multi-path.

73, Tom